第7章 見積り：当てずっぽうの奥義

7.1 概算見積りの問題

見積もりの目的

「ソフトウェア見積もりに主目的は、プロジェクトの結果を予言することではない。

見積もりを行うのは、プロジェクトのターゲットがコントロールによって達成可能な程度に現実的なものかどうかを判断するためである」

概算見積なんて当てずっぽうである。本来ありもしない工程を見積もってしまう

前もって見積ることはできない。

今後の計画を立てられる

見積りはあてずっぽうだという前提を踏まえている

ソフトウェア開発の複雑さを認めている

7.2 ピンチをチャンスに

相対サイズで見積もる

人間は絶対サイズの見積りは苦手で相対サイズの見積は得意とされている

ちいさいサイズのタスクからみて大きいサイズは何倍かという視点で見積もりをしていく

具体的な内容は以下

まずはストーリーに対して全員がどのくらいの大きさなのかを相対的に見積もる

次に開発チームがどれぐれいの速度で仕事を進められるか（ベロシティ）を計測する

アジャイル開発のおける相対サイズ1日は、カレンダーの1営業日とは限らない。開発スピードは一定ではないため。そのため、ポイントを使って見積もりをしていく

ポイントで見積もる

基本的にタスクは作業日数ではなくて仕事の大きさとして捉えて見積もる（服のLサイズ、Mサイズ、Sサイズなど）

見積が相対サイズになっていれば、ひとつひとつにストーリーに見積り違いがあっても、最後には辻褄はあうはず

次のメリットがある

見積とは当てずっぽいであることを肝に銘じることができる

見積とは純粋の大きさを測るものだと考えることができる（その方が見積り結果の賞味期限が長い）

手早く、気軽に、シンプルに見積もれる

研究結果からうまくいくことがわかっている

7.3 見積り技法

三角測量

代表的なストーリーを選出して、大・中・小で分別して、残りのストーリーに相対サイズで見積る方法

https://scrapbox.io/files/67f7e9cd05cab9568be8a36b.png

実際にストーリーを着手して、あきらかにポイントが違う場合は都度見直しをする

だが、ストーリー基準が適切だったら基本的にはそのままにしておいた方がいい。都度調整する手間が発生するり、ベロシティがスプリント毎にバラバラになる

どうしても経験がなく見積りができない場合は、スパイクという手法を使う

スパイクとはタイムボックス化された実験のこと。

見積もれるまで調査して見積もったら終わる

期間は数日でおさめるようにする

プランニングポーカー

開発メンバー全員がストーリーに対してポイントを割り振った後に、全員で共有しストーリーのポイントをきめる

開発メンバーが一致すれば決まりで、見積もり結果に違いがあれば合意できるまで議論する

この議論することに意味がある。仮に、1人だけポイントが大きく他の人が小さいポイントであれば、なぜ大きく見積もったかなどの議論に繋がる

プランニングポーカーがうまく理由は実作業者が見積もるから

投票システムではないことに注意、意見を出し合うことが重要

1・3・5ぐらいのストーリーサイズで見積もっていく。大きな値は必要ない。

できる限り見積りは正確あることを目指さないといけない。

しかしそれと同時に、自分で思っているほど正確には見積もれないことも心しておくこと。ストーリーを相対サイズで見積り、チームの開発速度を計測して初めて、計画はチームのいく先を照らす光となり、信頼のおける存在となる

by マスター・センセイ